System modeling and traceability applications of the higraph formalism

This report examines the use of higraphs as a means of representing dependencies and relationships among multiple aspects of system development models (e.g., requirements, hardware, software, testing concerns). We show how some well-known diagram types in UML have counterpart higraph representations, how these models incorporate hierarchy and orthogonality, and how each model can be connected to the others in a useful (and formal) manner. Present-day visual modeling languages such as UML and SysML do not readily support: (1) The traceability mechanisms required for the tracking of requirements changes, and (2) Builtin support for systems validation. Higraphs also deviate from UML and SysML in their ability to model requirements, rules, and domain knowledge relevant to the development of models for system behavior and system structure. To accommodate these demands, an extension to the basic mathematical definition of higraphs is proposed. Capabilities of the extended higraph model are examined through model development for an office network computing system. Last updated: September 24, 2007. Graduate Student, Master of Science in Systems Engineering Program, Institute for Systems Research, College Park, MD 20742, USA Associate Professor, Department of Civil and Environmental Engineering, and Institute for Systems Research, University of Maryland, College Park, MD 20742, USA, E-mail: [email protected] 1 System Modeling and Traceability Applications of the Higraph Formalism 1. PROBLEM STATEMENT Systems modeling is a fundamental component of the Systems Engineering process. Good modeling techniques allow for the comprehensive representation, organization, design, and evaluation of a system, from requirements, to structure, behavior, and beyond. Engineers are motivated to learn and use system modeling techniques in the belief that they enable and improve communication and coordination among stakeholders, thereby maximizing the likelihood of the right system being built correctly on the first try. Indeed, with a complete and correct system model in hand, ideally, implementation should be as simple as building the system per the model blueprint, which in turn, is represented through the use of system modeling languages. Unfortunately, this is where the grand vision of system modeling and the reality of present-day commercial engineering projects diverge. The problem is not that there are large flaws in current system modeling languages per se, but that existing system modeling languages (and associated model-driven methods) are relatively complex, and are difficult to use beyond the system modeling phase of the systems engineering lifecycle. In commercial settings, modeling languages in the form of popular commercial tools (see, for example, DOORS, SLATE and Visio [14, 22, 25]) are often forced into use by management on engineering projects. Too often personnel without true systems engineering skills are relied upon to use these tools, blindly, to create system models. If the underlying tools are implemented as islands of automation (or semi-automation) and are not connected together in a way that allows for flows of data/information among tools, then there is no automated way to create a trace from a requirement, to a component, to a behavior, to a test case. Support for change management is also weak due to the lack of a complete unified system model [2]. 2 1.1. Scope and Objectives The hypothesis of our work is that these modeling limitations can be be mitigated through the use of higraphs, a topovisual formalism introduced by David Harel in 1988 [10, 11]. To date, the higraph formalism has been applied to a wide range of applications including statecharts in UML (Unified Modeling Language) [26], expression of relationships in drawings [24] and urban forms [6], formal specifications in software development [19, 20], component-based development of web applications [29], and verification procedures in rule-based expert systems [20]. Higraphs have also made their way into Headway Software’s reView, a tool for management of large software code-bases (the source code, libraries, packages, etc..) [12]. The common thread among these applications is the use of nodes to represent allowable system states, and edges to represent transitions between states (system functions) and/or dependencies between states or viewpoints. Hierarchies can be shown through enclosure; concurrent activities can be shown through orthogonality relationships. Because systems engineering products and processes require many of the same characteristics, we surmise that higraphs might be a suitable abstraction for representing dependencies and relationships among multiple aspects of systems development models (e.g., hardware, software, electrical, mechanical concerns). Indeed, it is our contention that higraph representations can compliment, and perhaps even co-exist, with present-day UML and SysML representations of systems. This paper begins with a detailed introduction to the mathematical formalities of higraphs and directed acyclic graphs. Section 3 focuses on existing visual modeling languages, and examines the goals, strengths, and weaknesses of the Unified Modeling Language (UML) [26] and the Systems Modeling Language (SysML) [23, 24]. Section 4 covers the use of higraphs as a modeling tool for system requirements, system structure, and system behavior. We show: (1) how some well-known diagram types in UML have counterpart higraph representations, (2) how these models incorporate hierarchy and orthogonality, and (3) how each model can be connected to the others in a useful (and 3 formal) manner. To accommodate these demands, the basic mathematical definition of higraphs is extended in Section 5. Finally, in Section 6 capabilities of the extended higraph model are examined through model development for an office network computing system. 2. INTRODUCTION TO HIGRAPHS 2.1. Definition of Higraphs A higraph is a mathematical graph extended to include notions of depth and orthogonality. In other words [9]: Higraph = Graph+Depth+Orthogonality (1) We denote the term “graph” by G(V,E) where V is a set of vertices and E is a set of edges. The edges have no points in common except those contained in V. A directed graph is one in which the edges have direction – directed edges are called arcs (e.g., transitions in statechart diagrams). An edge sequence between vertices v1 and v2 is a finite set of adjacent and not necessarily distinct edges that are traversed in going from vertex v1 to vertex v2 [5, 8]. The left-most schematic in Figure 1 shows, for example, a small mathematical graph that is generic in the sense that the nodes and edges have arbitrary meaning. All that is defined here is that four nodes and three edges make up this graph. The central node has some sort of relationship to the three other nodes through the edges. The term “depth” in equation 1 can be thought of as a defined hierarchy, and the term orthogonality can be thought of as a Cartesian product or partitioning. Orthogonal states provide a natural mechanism for modeling of systems that contain disjoint but concurrent sub-system developments and/or concurrent component behaviors. Higraphs also incorporate Euler Circles (or Venn Diagrams) to define the “enclosure, intersection, and exclusion” elements. Harel